Thank you, can´t wait to see what we will get next :)

@penfold42
another question, makes it sense to add these udp listener to the booteffect array at the config (and Hyperion)? You can´t use both. Maybe to add a additional array would make sense?
Not sure where are the programming edges here.

I'm not sur I understand your question

ah!
this is like the receiver from proto/json just for udp and you will se also a booteffect at this device if the "sender" sends it?

Yep

It effectively turns Hyperion into a UDP driven led device just like my ESP8266 based wifi receiver.

I had 3 Pi's running the multicast effect and a perl script running on a 4th device sending 3 bytes per led (RGB) data over multicast to all Pi's at the same time.

My perl script/4th box could just as easily be a another Hyperion set up to use the UDP led device type

@penfold42
the idea is to refactor this to a UDP receiver (like "Boblight Server")
As part of a cleanup - this is a "misused" option (booteffect array)

I don't know what a booteffect array is.

We could write a native built in QT based UDP receiver if there's enough demand.
It could be implemented as a boblight level thing or we could consider it as a grabber

you use this

    "bootsequence" : 
    {
        "color" : [0,0,0],
        "effect" : "Rainbow swirl fast",
        "duration_ms" : 3000,
        "priority" : 700
    },

Which is a little bit "misused"
A general udp receiver component like this:

    "udpServer" : 
    {
        "port" : XXXXX
    },

would be cleaner

I havent been using it as a boot effect (although you could)

I've just been using Hyperion-remote when I need the UDP listener running

Yeah the handling could be "better" :)

hope to clear this conversation a bit:

current state of "udp listener":
its implemented as effect. This means it is absolutely OK to use it on every place where effects are usable - that includes the bootsequence of course.
If this effect should have some different handling than the other effects (e.g. own section in config), than we build an inconsistency in effect handling. I'm voting against that special treatment!

But yeah something is wrong here:
an effect uses setcolor/setimage to tell hyperion how the leds should glow. The udp effect is be definition an effect, but it does to much. It takes network input and then send it to lights. If we wouldn't have json- proto- boblight server, I would say all things are right.
But we have already codeparts that makes network to light. The new "network to light" function for udp protocols should be implemented in the way how any other "network to light" stuff in hyperion.
=> @penfold42 realized this already

It could be implemented as a boblight level thing

and have the right solution (please don't do this as grabber, thx). Thing is, doing this in python as an effect is much faster (to develop), then doing this the clean way as own hyperion network service.